Link against system-cxx-std-lib for GHC 9.4+ #197
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dpwiz
reviewed
Feb 21, 2024
This issue was fixed by commercialhaskell/pantry#131, which was included in |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When testing a Windows application using
dear-imguiandfile-embedwith GHC 9.4.8, I bumped into this build issue:The same application worked fine on Mac and I'm not yet familiar enough with Windows development to understand why the Windows side wasn't happy. Regardless, following the recommendation in the linked issue and the GHC 9.4 migration guide to link against the virtual
system-cxx-std-libinstead ofstdc++for 9.4+ gets things working on Windows and the Mac build continues to work.Unrelated to this PR's changes, but I also hit the error described in #58 when trying to get the Windows build working. I'm assuming this is a problem with
stack's behavior on Windows, where it seemingly does not fetch theimguisubmodule.stackdoes get the submodule on Mac without issue. I worked around this on Windows for now by depending on a local copy ofdear-imguithat had the submodule contents manually fetched.Ideally the issue in
stackwill get resolved and it's something I'd like to look at time-permitting, but as food for thought, I wonder if friction would be reduced in the long run if this repo included a copy of the ImGui source rather than submoduling it in.